Modding/Terms
Intro Terminology and property names you will encounter in the Call to Arms data files. This is very much a work in progress with several unanswered questions. There is an important distinction in the data files between simple properties, and macros--which are are shortcuts that can refer to a whole complex set of properties. Read the Data File Syntax section if you're planning on doing any detailed work with data files. List of Properties Key *'bold' = property name *'"quotes"' = macro name *''italic'' = concept The Big Properties List *''accuracy'': ... *''armor'': Vehicle armor is defined in each vehicle DEF file. The units are mm of RHA (the same as projectileDamage). **While basic armor properties are found in each vehicle's *.def file, these almost always reference macros and presets found in gamelogic\properties\car.ext, and other *.ext files. **At it's most detailed it is noted in the form (front side rear top) for the given vehicle part: body, turret, etc. **Armor slope and facing (front, side, etc.) are derived from the 3D model file. These hit "volumes" are simplified convex shapes linked to the model but invisible in game. ***As long as the hit volumes are roughly shaped to follow the actual armor shape (as the in-game models do), thickness values should represent the armor thickness along the normal (i.e. the smallest value, not 'effective armor thickness'). ***Armor slope (from the 3D model) and the weapon impact angle are correctly factored together to yield effective armor thickness for each weapon impact. ***NOTE: Many vehicles list more than one "body" entry for armor; this is simply because their armor volume in the 3D model file is broken up into multiple pieces to keep everything convex as required by the game engine. The armor values should just be duplicates of each other. **Wheel & track armor is defined centrally for all vehicles in gamelogic.pak\resource\properties\vehicle.ext *'"damage"': creates a projectileDamageTable, which is a range-damage table for heavy weapons. The only difference is that the ranges are preformatted in the macro. **Range-damage tables using this macro are formatted like this: ("damage" a(800) b(600) c(400) d(200) e(100)) ;the letter indicates the a preset range ;(look in the .presets file to see the range each letter refers to) ;the (#) represents the amount of projetileDamage (mm of RHA penetration). *'filling {"ammo name" # #}': The first # is the quantity of rounds per magazine, the second # is the total quanity of rounds carried. *'gravity': Rate of shell drop. Units unknown. *'health': Hit points for humans, animals. Depleted when damaged. Regained over time and by applying med kits. See healthDamage. *'healthDamage': 'Hit point' damage to humans (animals, etc) caused by a weapon. Not to be confused with projectileDamage. (Arbitrary units obvs.) *'healthRegeneration': Controls how fast a unit naturally regains health over time. *''morale'': A morale bar has been added to the game, but it may be exclusively controlled by code at this point--there don't appear to be any properties relating to it exposed in the data files... yet. *'projectileDamage': Weapon penetration in mm of RHA. This is used by the game to calculate vehicle damage. Not to be confused with healthDamage. **(?)After factoring in armor slope and weapon impact angle, over-penetration of several mm appears to be necessary to cause damage to a vehicle. It may be necessary to exceed real-world penetration values by some amount or %age to get realistic damage effects in the game. *'projectileDamageClip': ?? *'projectileDamageTable': A type of range-damage table that doesn't use letter presets for range (a,b,c, etc.) and is instead in the form {range damage}. e.g. {projectileDamageTable {50 5} {250 0}} ;Weapon does 5 projectileDamage at 50m, dropping to 0 at 250m ;(The relationship between the data points is linear) *'projectileDamageThreshold': ...? *''range'': Range is in units of meters. **NOTE The default game foreshortens all ballistics by at least a factor of 10(!) compared to real-world values. The projectileDamage drop off is absurdly extreme and was clearly intentionally exaggerated. **Some range-damage tables have a set of preset values defined, e.g., in gamelogic\set\stuff\gun\.presets. %a=10m, %b=50m, %c=100m, %d=150m, %e=200m. A weapon's projectileDamage is broken down by range, e.g. ("damage" a(800) b(600) c(400) d(200) e(100)) ;At 10m, the weapon does 800 projectileDamage, by 50m it does 600, and so on. ::*The relationship between datapoints appears to be linear. *'rechargeTime': Time in seconds to load a new magazine in the weapon. "reloadTime" might have been a better term. :) *'recoveryTime': (?) Delay in seconds between one shot and the next. *'"speed" s(#)': Shell speed in meters/second. This doesn't seem to affect the damage calculation. Rather it controls how fast a projectile moves, affecting aim accuracy, especially in first person / direct control mode. **NOTE: speed is not differentiated by ammo type as often as it should be, but this can be easily corrected to match real world values, e.g. ("speed" s(1650)) <--default speed of shell for this gun ("damage" a(1400) b(1200) c(1000) d(800) e(600)) {parameters "heat" ("speed" s(975)) <--ADDED separate (slower) speed value for HEAT shell ("damage_cumulative" a(1000)) } *'stamina': Used up when a human moves fast. Dependent on weight carried. *'staminaRegeneration': Controls how fast a unit naturally regains stamina over time. Data File Syntax The text-based data files are formatted in the (??) language. Properties { } Inside braces { }, property value(s) are defined directly. They gets read by the game and passed into game variables that control something: tank speed, weapon damage, whatever. ;these are two different simple properties that just define one value each: {rechargeTime 6.5} {fireSound "small_arms/m240/"} ;this compound set of properties defines multiple paired values: {projectileDamageTable {50 5} {250 0}} ;Note the formats: {property numbervalue} {property "textvalue"} Macros ( ) Inside parenthesis ( ), a macro is defined. A macro is a shortcut to a property or a bunch of properties. It's a way of saving space in the data files by centralizing some preset properties. But you have to locate it's definition (often in a different data file) if you want to know what it's actually doing. Explicit-Style Definition ;Here is a macro being called: ("damage" a(1000) b(800) c(600) d(400) e(200)) ;...And here is its definition (which actually lives in a different data file): (define "damage" {projectileDamageTable {10 %a} {50 %b} {100 %c} {150 %d} {200 %e} {1000 0}} ) ;Note the definition format: (define "macro name" {property %variablename} ) ;... and the corresponding macro format: ("macro name" variablename(value) ) Implicit-Style Definition There is a second way to define macros, usually found in older MoW data files: ;Here is an "implicit-style" macro being called: ("damage" args 1000 800 600 400 200) ;...And here is what its definition would look like: (define "damage" {projectileDamageTable {10 %0} {50 %1} {100 %2} {150 %3} {200 %4} {1000 0}} ) ;Note the definition format: (define "macro name" {property %variable#} ;<--these #'s must be assigned in order starting with %0 ) ;... and the corresponding macro format: ("macro name" args value) ;<--values entered starting with the one for %0 *You don't have to use macros when making your own data files. You can just work with properties directly. But you need to know how macros work if you are going to edit existing data files, because they use macros liberally. *...And that means digging through the data files, and finding the relevant (define) so you understand what underlying properties are being manipulated. *Macros are very useful shortcuts for quickly changing values across lots of different units, so it's a good idea to learn how the default ones work. Inheritance & Linked Files Data files can link to other data files. Pattern Many data files start with syntax like this: {from "pattern bullet" ... } *In the above example, the data file inherits the properties of a file called "bullet.pattern". And it overrides some of those values with whatever is added between the braces. *Data files seem to be able to inherit *.pattern files that are not in the same folder (some are, some aren't). There are examples where the *.pattern file is one folder above the data file. Include Files can also include a reference with an 'include', e.g. (include "vehicle.ext") Preset Meanwhile, many folders have a .preset file in them. This file contains macro definitions that are available to all the data files in the same folder. Investigating... *{parameters}: Data file control syntax. (?)Allows different values to be set by ammo type: "heat", "fg", "ap" **{parameters} is used in other ways as well, not clear how those ones work. *{extender}: Data file control syntax. *const: Presumably "constant", but why it is used to assign only a few values is not clear. *{Weaponry}: Something to do with weapons, bones, and aiming *{RestoreIKAfterAim} in some vehicle def files *{AimingTolerance} in bullet.pattern and a few other files. Supposedly affects AI only by telling them how far off their aim can be while still allowing them to fire a weapon. Category:Modding